HIP Node Reachability

ABSTRACT

A method of configuring a plurality of rendezvous servers to provide a Host Identity Protocol, HIP, based mobility service to HIP nodes, where the servers are arranged in a hierarchical branching structure. For each HIP node, a Host Identity Tag, HIT,-and contact address mapping is registered with a rendezvous server ( 101 ). That server then identifies itself and the HIT to each higher level server within the same branch, without explicitly identifying the contact address to those higher level servers ( 103 ) wherein, in use, when a first rendezvous server receives a HIP contact message addressed to a given HIT ( 201 ), if that first server is unaware of the destination HIT, it forwards the message to a higher level server within the same branch ( 204 ), and if the first server is not the server at which the HIT is registered but is aware of the HIT, it forwards the contact message to the neighbouring rendezvous server corresponding to the HIT ( 203 ).

TECHNICAL FIELD

The present invention relates to reachability of a mobile HIP node in anIP network when Rendezvous Servers are used.

BACKGROUND

In the Host Identity Protocol (HIP) [1] Working Group at the IETF thereis a draft on Rendezvous Server (RVS) functionality [2]. An RVS is usedas a fixed anchor point from which a mobile HIP node can be reached. AHIP node registered at an RVS informs the RVS of the locators via whichthe HIP node is reachable. This way HIP nodes that want to contact themobile HIP node can always reach it via the RVS that has up-to-datelocator information of the mobile HIP node.

To be able to utilize the RVS for locating another HIP node, the HIPnode initiating the connection needs to know the locator of the RVS. Thecurrent proposal is that the IP address of the RVS is found in DNS alongwith the Identity of the mobile HIP node. However, this requires thatinformation is updated at the DNS for each HIP node that wants to beregistered at an RVS. This might not be feasible in all situations, e.g.in military networks or other more or less private networks that atleast partly share the public network infrastructure. In these networksit might also be that DNS is not available at all or is only availablesporadically.

Robustness of the RVS system is also a problem in the current solution.For example, if an RVS is suddenly removed from the network, it is notpossible to contact a destination host registered at the RVS even ifthere is a path to that host.

The article entitled “A HIP Based Network Mobility Protocol”, SzabolcsNováczki, Proc. of the 2007 International Symposium on Applications andthe Internet Workshops (SAINTW'07), 15-19 Jan. 2007, describes a HIPextension for supporting moving networks. The proposal makes use of ahierarchical local rendezvous server (LRVS) structure to route trafficbetween the Internet and mobile nodes. For a given mobile node,following registration with the local network, traffic will always passbetween the LRVS server to which the node is registered and the rootLRVS that connects to the Internet. Within the Internet the RVSstructure described above is implemented. As discussed, this RVSStructure can make use of the DNS to allow HIP nodes to determinecontact information for peer nodes (using a HIT lookup). The LRVSstructure does not itself allow mobile nodes registered with the localnetwork to identify contact addresses for peer nodes.

SUMMARY

The disadvantages noted above may be overcome by implementing an RVSserver hierarchy, and passing HIP registration information up throughthe hierarchy from the registration server to a top lever server. Inthis way contact requests can be referred up the hierarchy if necessaryuntil a knowledgeable server is identified. Moreover, only theregistration server, and possible certain servers within a cluster atthe same level, needs to be aware of the actual contact address for aHIP node, reducing signalling at node mobility.

According to a first aspect of the invention there is provided a methodof configuring a plurality of rendezvous servers to provide a HostIdentity Protocol, HIP, based mobility service to HIP nodes, where theservers are arranged in a hierarchical branching structure. For each HIPnode, a Host identity Tag, HIT, and contact address mapping isregistered with a rendezvous server. That server then identifies itselfand the HIT to each higher level server within the same branch, withoutexplicitly identifying the contact address to those higher level serverswherein, in use, when a first rendezvous server receives a HIP contactmessage addressed to a given HIT, if that first server is unaware of thedestination HIT, it forwards the message to a higher level server withinthe same branch, and if the first server is not the server at which theHIT is registered but is aware of the HIT, it forwards the contactmessage to the neighbouring rendezvous server corresponding to the HIT.

Embodiments of the invention may avoid the need for a DNS to identify toan originating HIP node an RVS that knows the location of a destinationHIP node. Rather, a contact message is routed up through the RVShierarchy until it reaches an RVS that either knows the contact addressfor the destination node or knows the identity of another RVS in thebranch towards such an RVS.

Following registration of a HIP node at a registration rendezvousserver, a notification may be sent from that registering server to oneor more other servers within the same hierarchical layer to identify tothe other server(s) the HIT to contact address mapping for the HIP node.This creates a cluster of servers which are all aware of the contactaddress of a HIP node and which can therefore all forward a HIP contactmessage to the HIP node. For reasons of signalling efficiency, saidnotification may be sent to servers within the same geographic region asthe registration server.

In order to authenticate a server claiming to have registered a HIPnode, upon registration of a HIP node the registration rendezvous servermay send notifications to other servers accompanied with a certificateverifying that the registration server is an approved server.Alternatively, authentication may be based upon a pre-established trustrelationship between servers.

In a particular scenario, both the destination HIP node and theoriginating HIP node of said HIP contact message are registered with oneof said rendezvous servers.

According to a second aspect of the present invention there is provideda method of operating a HIP based network comprising a plurality ofrendezvous servers configured according to the above aspect of theinvention, the method comprising receiving an I1 HIP contact message ata rendezvous server and, if the rendezvous server is unaware of thedestination HIT, forwarding the I1 message to a rendezvous server higherin the hierarchical server structure.

According to a third aspect of the present invention there is providedmethod of operating a rendezvous server for use in providing a Hostidentity Protocol, HIP, based mobility service to HIP nodes. The methodcomprises receiving a HIP contact message destined for a HIP node and,if the server is aware of the destination HIT, forwarding the contactmessage to a contact address associated with the HIT or to anotherrendezvous server associated with the HIT and positioned lower in ahierarchical rendezvous server structure. On the other hand, if theserver is unaware of the destination HIT, the contact message isforwarded to another rendezvous server positioned higher in thehierarchical rendezvous server structure.

According to a fourth aspect of the present invention there is providedrendezvous server for use in a Host Identity Protocol, HIP, basednetwork, the rendezvous server being arranged to register Host IdentityTag, HIT, to contact address mappings for HIP nodes. Upon registration,the registering server informs one or more other rendezvous serverspositioned higher in the hierarchical rendezvous server structure thatit knows the contact address for the HIP node without explicitlyidentifying the contact address.

Features may be implemented in the rendezvous server in order toimplement features of the methods set out above.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates schematically an example of a RVS hierarchy withthree levels;

FIG. 2 illustrates schematically a rendezvous server suitable for use inthe hierarchical structure of FIG. 1;

FIG. 3 is a flow diagram illustrating a process for configuring thestructure of FIG. 1; and

FIG. 4 is a flow diagram illustrating a process for message handling atthe rendezvous server of FIG. 2.

DETAILED DESCRIPTION

Abbreviations used in the following discussion include:

DNS—Domain Name System

HIP—Host Identity Protocol

IETF—Internet Engineering Task Force

RVS—Rendezvous Server

WG—Working Group

There is proposed here a hierarchical and robust RVS architecture. Theregistration information is shared between RVSs that, from a networkperspective, are close to each other. All of these RVSs can be used forlocating the mobile HIP node, not only the one at which the HIP node isregistered. Furthermore, information identifying the RVS knowing theLocation of a mobile HIP node is shared with RVS(s) at a higher level inthe RVS hierarchy. These higher level RVSs do not know the actualcurrent location of the HIP node, i.e. its contact (IP) address, but areable to identify RVSs having that information. If an RVS does not knowthe target host for an I1 packet (Initiator 1 packet), the I1 packet issent up the RVS hierarchy until an RVS is found that knows how to reachthe target. This reduces the signalling needed for keeping the RVSs'states up-to-date. An example RVS hierarchy with three levels isillustrated in FIG. 1.

When a Mobile Node attaches to a new network it will start the servicediscovery procedure to find the nearest RVSs. Once these are identified,it will select one of these and run the HIP base exchange as describedabove, containing the registration extensions (parameters needed for theregistration procedure). In addition the Mobile Node includes a sequencenumber (“birthday counter”) or timestamp into the registration requestwhich is used if the RVS already has an entry for the particular MobileNode. The counter will identify which of the registrations is the mostrecent, effectively invalidating other information within the network.

For more flexible RVS configuration the Mobile Node includes acertificate with the registration request giving the RVS rights todelegate the registration information further in the network. The usageof this certificate will be described below in more detail.

Groups of RVSs at Level III share up-to-date location information. TheRVSs at Level III thus always have up-to-date location information aboutthe subset of hosts that are registered to any of the RVSs that shareregistration information between themselves. In FIG. 1, RVS 7, 8 and 9belong to the same group and all have up to date information on MobileNode B including the HIT to contact address mapping.

An RVS with which a HIP node registers, communicates to the next higherlevel RVS within the same branch the fact that it knows the location ofthe HIP node, i.e. it communicates the mapping between its RVS identityand the HIT of the HIP node. It does not communicate explicit locationinformation for the node however. Thus, whilst the higher level RVS doesnot know the location of the mobile node, it knows that the lower layerRVS knows this information. In the example of FIG. 1 this means that RVS2 learns that RVS 5 knows how to reach Mobile Node A. Similarly, thathigher layer RVS communicates to the next higher layer RVS the fact thatit knows how to reach the HIP node, and so on until the chain to thetopmost RVS (in this case RVS 1) is complete.

It will be appreciated that contact address changes for a HIP node needonly be relayed to the RVS with which the HIP node is registered, and toother RVSs at the same layer and within the same information sharinggroup. There is no need to pass this information to higher layer RVS.Cross level updates are only necessary when a new HIP node is registeredat Level III or when a HIP node removes its registration at an RVS (bothevents occur of course when a HIP node changes its registration RVS).

In the example of FIG. 1, only the RVSs on Level III have HIP nodesregistered with them. Of course, all RVSs may accept registrationsregardless of their level in the hierarchy. Moreover, a given RVS in theillustrated architecture could actually be implemented as a cluster ofRVSs, resulting in a more robust architecture.

Considering further the example architecture of FIG. 1, Mobile Node Aregisters at RVS 5. RVS 5 then propagates the registration informationto RVS 2, whereby RVS 2 knows that Mobile Node A can be reached via RVS5, but does not need to know each time that Mobile Node A gets a newlocator, since it will anyway still be reachable via RVS 5. Furthermore,RVS 2 propagates the registration information to RVS 1, which in turnlearns that RVS 2 knows how to reach Mobile Node A. Alternatively; RVScould also learns that RVS 5 knows how to reach Mobile Node A. In eithercase, RVSs 3, 4 and 6 to 9 are unaware of Mobile Node A, i.e. they donot know a contact address for Mobile Node A and nor do they explicitlyknow an RVS that knows how to reach Mobile Node A.

When Mobile Node B registers at RVS 8, the registration information willbe “spread” by RVS 8 to RVS 7 and RVS 9. All three RVSs (7, 8, and 9)will also inform the next RVS in the hierarchy, here RVS 4, that theyknow how to reach Mobile Node B. RVS 4 further informs both RVS 3(secondary information) and RVS 1 that it can get packets delivered toMobile Node B.

When Mobile Node B wants to contact Mobile Node A, it sends the I1packet to its RVS (the RVS it is registered at), here RVS 8. Since RVS 8is unaware of Mobile Node A, it forwards the I1 packet to RVS 4. At thispoint, if Mobile Node A would have been registered at RVS 6, the I1packet would have been forwarded to RVS 3 and from there to RVS 6 andfinally Mobile Node A. However, as this is not the case and RVS 4 isagain unaware of Mobile Node A, it forwards the I1 packet still higherin the branch to RVS 1. RVS 1 has received second-hand registrationinformation and knows that RVS 2 can help with delivering the packet.RVS 1 therefore forwards the I1 packet to RVS 2. When RVS 2 receives thepacket it sends it to RVS 5 which does know where Mobile Node A islocated and can forwards the packet to it. After this first HIP baseexchange packet (I1), the remaining messages of the HIP base exchangeare routed directly between Mobile Nodes A and B. The RVS hierarchy isthus used only as a mechanism for routing the first HIP contact message.

Considering further the sharing of information between RVS, either atthe same level between levels, there are two approaches to ensuresecurity:

-   -   a) a trust relationship between the RVSs, with each RVS knowing        the identity and locator of other RVSs that it will need to        communicate with and trusting these RVSs.    -   b) RVSs are given a certificate signed by the root RVS (RVS 1 in        FIG. 1), which can be provided to a peer RVS in order to allow        that peer RVS to verify that the other RVS has been accepted by        the root RVS.

In alternative a), each RVS accepts information it receives from any ofthe preconfigured RVSs. Alternative b) allows for a more flexiblenetwork; a new RVS can be added without having to reconfigure all RVSsthat might need to communicate with the new RVS. In case b), whenregistration information is received, at an RVS from a previouslyunknown RVS, the registration information will contain a certificatethat proves that the, sending RVS has been approved by the root RVS (RVS1). Here the root RVS is acting as a Certificate Authority (CA). Whenthe two RVSs have established a HIP association and verified the otherRVS's certificate (using the public key of the root RVS), they canexchange registration information. Once two RVSs have verified eachothers certificates they can in the future directly accept registrationinformation from each other (as long as the certificate is valid). Allcommunication between the RVSs is done over the HIP association, whichgives secure communication and peer authentication.

In the case that an RVS does not have a certificate signed by the rootRVS, the RVS could still be accepted by the network. When a Mobile Noderegisters at a first RVS unknown to the network, the Mobile Node mayprovide the first RVS with a certificate accepting the first RVS as itsRVS. The first RVS can provide that certificate to another RVS withwhich it wants to share registration information. The RVS receiving thecertificate can verify that the Mobile Node has signed the certificatefor the unknown RVS and that the Mobile Node's own certificate has beensigned by the root RVS (or other trusted CA like entity), and canthereby accept the unknown RVS into the RVS hierarchy. Even if theunknown RVS turns out to be malicious, the only harm it can do is toperform a DoS (Denial of Service) attack on the Mobile Node(s) thatprovided the certificate (i.e. by not forwarding I1 packets to and fromthe Mobile Node).

In the ease that an RVS is suddenly removed, it remains necessary to beable to locate the HIP nodes registered at the removed RVS. RVSs withinthe same group or cluster need to be alerted to the removal. This couldbe achieved for example by exchanging “keep alive messages” between RVSswithin the same group (and optionally between Mobile Nodes and RVSs).When an RVS, e.g. RVS 8 in FIG. 1, is removed, RVSs 7 and 9 notice thisby the lack of response to their keep alive messages: At this pointthere are two possibilities:

-   -   a) The RVSs assume that the mobile node(s) registered at RVS 8        will notice that RVS 8 is no longer present and that they will        therefore perform HIP service discover [3] to find a new        suitable RVS with which to register. RVSs 7 and 9 will preserve        the registration information received from RVS 8 until a        registration timer expires or until they receive new        registration information from the mobile node(s).    -   b) The remaining RVSs in the group can try to establish a new        registration context with the mobile node(s) previously        registered at RVS 8, thus maintaining reachability to them. This        requires that the registration initiated from an RVS contains        information identifying the registration it is attempting to        replace. Using this information a mobile node can verify that        its old RVS is no longer reachable, and register at one of the        remaining RVSs in the group. When the RVS initiated registration        is completed, the new registration entry is distributed to other        RVSs.

A combination of these two possibilities can be considered. Firstly,option b) is utilized, and if the RVSs do not manage to create newregistration contexts with the mobile node(s) they utilize option a) andrely on the mobile node(s) performing service discovery once theirprevious registration expires and they determine that the old RVS is nolonger available.

Another registration related issue arises when a mobile node moves faraway from the RVS at which it is registered. This is undesirable as mostHIP connections are likely to be established between geographicallyclose mobile nodes, and it might be that the connections between levelIII and level II involve more expensive links, e.g. satellite links.Minimizing the use of the expensive link can be done by changing theused RVS. In any case, it is always desirable to optimise the forwardingpaths for contact messages through the RVS hierarchy.

To this end, when a mobile node changes its access network, it couldautomatically perform HIP service discovery to locate RVSs in the newnetwork. If it finds an RVS that already contains registrationinformation for its HIT (in this case the discovered RVS may abort theregistration attempt), the mobile node knows that it is still locatedclose enough to its current RVS and can continue using it. In the casethat the found RVS does not have registration information for the HIPnode, e.g. in FIG. 1 if Mobile Node B finds RVS 6, it means that theMobile Node B should change its RVS. Then the Mobile Node B sends adelete registration message to the RVS at which it currently isregistered (RVS 8 in this example), and at the same time performsregistration at the new found RVS (RVS 6). When the old RVS (RVS 8)receives the delete registration message it removes the registrationinformation of the mobile node (Mobile Node B) and propagates the deleteinformation in the same manner as if it were an add registrationoperation.

When a mobile node moves behind a new RVS that does not have aconnection to the main network, then the old registration can not bedeleted. If and when the new RVS becomes attached to the main networkthere will be dual RVS entries for the mobile node in the network; theold entry which could not be deleted, and the new entry. To handle thissituation all registrations should have a sequence number or timestampwhich can be used for deciding upon which entry is the current one.

FIG. 2 illustrates schematically a rendezvous server 10 for use in thehierarchical structure described above. The RVS comprises a firstinterface 11 for communicating with a higher level RVS within the samebranch, and a second interface 12 for communicating with a lower levelRVS in the same branch. A third interface 13 is used to communicate withRVSs within the same level., whilst a fourth interface 14 allows the RVSto communicate with mobile nodes. The RVS 10 comprises a main processor15 which examines incoming I1 messages (received over one of theinterfaces) to determine if it is aware of the destination HIT containedwithin the message and handles them accordingly. The RVS comprises alookup memory 16 which contains registered HIP mappings, either HITs toHIP node contact addresses, or HITs to next hop RVS identities.

Considering now FIG. 3, this illustrates the process for configuring theRVS structure, from the point of view of a level III RVS. The processbegins at step 100, with the RVS performing a registration for a HIPnode at step 101. In particular, the RVS registers the HIT to contactaddress mapping for the HIP node. At step 102 the RVS sends the mappingto other RVSs within the same level and which are within the same RVScluster. At step 103 the registering RVS informs the next level RVSwithin the same branch that it knows the mapping for the HIT, but doesnot provide the contact address. The process ends at step 104.

FIG. 4 is a flow diagram illustrating the I1 message handling processcarried out at an RVS. The process begins at step 200, with the RVSreceiving the I1 message at step 201. At step 202 the RVS determineswhether or not it is aware of the destination HIT. If the answer is yes,at step 203 the RVS forwards the I1 to the registered contact address ifthis RVS is the registering RVS, or forwards it to the next hop RVS,i.e. down to the next level RVS within the chain towards the registeringRVS. If the RVS is unaware of the destination HIT, at step 204 the RVSpasses the I1 to a higher level RVS which will either be aware of thedestination HIT or will continue to pass the I1 up to the next level.The process ends at step 205.

Advantages of the architecture described here include the possibility touse any RVS for reaching a mobile HIP node, instead of having to use theone at which the mobile node is registered. The architecture also makesthe RVS system more robust by sharing the registration information andeliminating the single point of failure issue. The concept of changingthe serving RVS by outdating the information at the old RVS isintroduced.

It will be appreciated by the person of skill in the art that variousmodifications may be made to the above described embodiments withoutdeparting from the scope of the present invention.

1. A method of configuring a plurality of rendezvous servers to providea Host Identity Protocol, HIP, based mobility service to HIP nodes, themethod comprising: arranging the servers in a hierarchical branchingstructure; for each HIP node, registering a Host Identity Tag, HIT, andcontact address mapping with a rendezvous server, and identifying toeach higher level server within the same branch the HIT and aneighbouring or other lower level server within the branch, withoutexplicitly identifying the contact address to those higher levelservers, wherein in use, when a first rendezvous server receives a HIPcontact message addressed to a given HIT, if that first server isunaware of the destination HIT, it forwards the message to a higherlevel server within the same branch, and if the first server is not theserver at which the HIT is registered but is aware of the HIT, itforwards the contact message to the neighbouring or other lower levelrendezvous server corresponding to the HIT.
 2. A method according toclaim 1 and comprising, following registration of a HIP node at aregistration rendezvous server, sending a notification from thatregistering server to one or more other servers within the samehierarchical layer to identify to the other server(s) the HIT to contactaddress mapping for the HIP node.
 3. A method according to claim 2 andcomprising sending said notification to servers within the samegeographic region as the registration server.
 4. A method according toany one of the preceding claims, wherein upon registration of a HIP nodethe registration rendezvous server sends notifications to other serversaccompanied with a certificate verifying that the registration server isan approved server.
 5. A method according to any one of claims 1 to 3,wherein upon registration of a HIP node the registration rendezvousserver sends notifications to other servers with which it has anestablished trust relationship.
 6. A method according to any one of thepreceding claims, wherein said contact address is an IP address.
 7. Amethod according to any one of the preceding claims, wherein both thedestination HIP node and the originating HIP node of said HIP contactmessage are registered with one of said rendezvous servers.
 8. A methodaccording to any one of the preceding claims, wherein said step ofidentifying to each higher level server within the same branch the HITand a neighbouring or other tower level server within the branch,comprises informing, each server above the server at which the HIP nodeis registered of the HIT and the identity of the registering server. 9.A method according to any one of claims 1 to 7, wherein said step ofidentifying to each higher level server within the same branch the HITand a neighbouring or other lower level server within the branch,comprises identifying to each higher level server in the same branch theHIT and an identity of the neighbouring server lower level server.
 10. Amethod of operating a HIP based network comprising a plurality ofrendezvous servers configured according to any one of the precedingclaims, the method comprising receiving an I1 HIP contact message at arendezvous server and, if the rendezvous server is unaware of thedestination HIT, forwarding the I1 message to a rendezvous server higherin the hierarchical server structure.
 11. A method of operating arendezvous server for use in providing a Host Identity Protocol, HIP,based mobility service to HIP nodes, the method comprising: receiving aHIP contact message destined for a HIP node and, if the server is awareof the destination HIT, forwarding the contact message to a contactaddress associated with the HIT or to another rendezvous serverassociated with the HIT and positioned lower in a hierarchicalrendezvous server structure and, if the server is unaware of thedestination HIT, forwarding the contact message to another rendezvousserver positioned higher in the hierarchical rendezvous serverstructure.
 12. A rendezvous server for use in a Host Identity Protocol,HIP, based network, the rendezvous server being arranged to registerHost Identity Tag, HIT, to contact address mappings for HIP nodes and,upon registration, to inform one or more other rendezvous serverspositioned higher in the hierarchical rendezvous server structure thatit knows the contact address for the HIP node without explicitlyidentifying the contact address.
 13. A rendezvous server according toclaim 12 and being arranged at registration of a HIP node to inform oneor more other rendezvous server within the same layer of thehierarchical structure of the HIT to contact address mapping.
 14. Arendezvous server according to claim 13 and being arranged to send saidnotification to servers within the same geographic region as theregistration server.
 15. A rendezvous server according to any one ofclaims 12 to 14 and being arranged, upon registration of a HIP node, tosend notifications to other servers accompanied with a certificateverifying that the sending server is an approved server.
 16. Arendezvous server according to any one of claims 12 to 14 and beingarranged, upon registration of a HIP node, to send notifications toother servers with which it has an established trust relationship.
 17. Arendezvous server according to any one of claims 12 to 16, wherein saidcontact address is an IP address.